Thank you!

Thank you for your pull request 😃

🤖 This automated message can help you check the rendered files in your submission for clarity. If you have any questions, please feel free to open an issue in {sandpaper}.

If you have files that automatically render output (e.g. R Markdown), then you should check for the following:

• 🎯 correct output
• 🖼️ correct figures
• ❓ new warnings
• ‼️ new errors

Rendered Changes

🔍 Inspect the changes: https://github.com/carpentries/instructor-training/compare/md-outputs..md-outputs-PR-1558

The following changes were observed in the rendered markdown documents:

 17-live.md | 56 ++++++++++++++++++++++++++++++++++++--------------------
 md5sum.txt |  2 +-
 2 files changed, 37 insertions(+), 21 deletions(-)

⏱️ Updated at 2023-08-02 13:14:34 +0000

@brownsarahm - I am internally amused about people reading "live demo" and then expecting to see "Carpentries Live Demolitions", but your suggestion is excellent!

Following today's discussion in the trainer meeting, my consideration into this change comes to this:
If we teach a cohort of trainees with no experience coding, programming, developing software, then it is up to us to explain the place of live coding in our pedagogy, and our emphasis on "participatory live coding". I don't agree with the wholesale change to replace 'coding' with 'demonstration' or other general presentation forms because it takes the learner away from the new mental model that we are teaching, which is associated explicitly with programming skills. When words and concepts are unfamiliar to learners, we can teach them to embrace the discomfort.

The reason I don't fully agree with this is that we do, in fact, have quite a bit of curriculum that does not involve coding. The open refine and spreadsheet lessons in the DC and LC curricula, at least. I would even go so far as to say that the Git lessons don't strictly speaking teach coding, but rather interactively interacting with Git on the command line.

The point, as I understand it, is not to avoid the word "coding" because it might be unfamiliar or intimidating, but to specifically be inclusive of people who are teaching those lessons, and to avoid confusion by making it clear that the live participatory stuff that we do is not limited to coding.

I really appreciate @ragamouf's comment

When words and concepts are unfamiliar to learners, we can teach them to embrace the discomfort.

I propose that we take a careful read through how we are framing things in this episode that we always do "participatory live demonstration" and that it is mostly "participatory live coding".

We want to include people who want to teach data organization in spreadsheets or cleaning with openrefine, but not affirm people's fear of coding. We teach in this lesson about meeting our learners where they are and encouraging them to use these tools even if they are afraid, I think we need to keep modeling that here.